System and Method for Trading Options

ABSTRACT

A system and method of trading option contracts, such as foreign currency option contracts, is described. In one embodiment, a system and method for web-based or network-based interactive trading of currency options is described. Users of the system provide volatility runs of currency options, deal on existing offers to sell or bids to buy, or may improve on existing offers to sell or bids to buy. Option contracts may be priced in units of volatility. Users of the system described include banks of all sizes and traders or dealers employed by banks or other financial institutions. The system and method provide automatic price quotations for a requested option contract by polling internal volatility surfaces of users for prices on the requested contract. Additionally, the system and method ensure a more orderly pattern of trades by categorizing the users into discrete tiers which determine a user&#39;s obligations to provide offers and bids to the system and which determine a user&#39;s opportunities and rights to trade on the system. Furthermore, a system and method is described for automatically withdrawing quotes for offers to sell or bids to buy option contracts after expiration of a prescribed period of time or prescribed movement in the market underlying the option contract.

FIELD OF THE INVENTION

The invention is directed to a system and method for trading optioncontracts such as currency options.

BACKGROUND OF THE INVENTION

A buyer of an option contract acquires a right to buy a specificproperty at a specified price within a specified period of time. Thereare markets for trading in option contracts for currency, commodities,stocks, bonds and other financial instruments. Options trading presentsunique problems, and therefore computerized trading of such options overnetworks accessed by remote users must be tailored for use in optionstrading.

Banks that provide currency option products to their clients also dealwith each other in order to manage currency risk. Currency options inthe interbank market are primarily traded between banks on a one-to-onebasis (direct market) or are brokered by a currency options broker(broker market).

In the direct market, banks communicate with each other directly. Onebank contacts another requesting a price on an option contract that itwishes to buy or sell in order to manage the risk in its portfolio. Thebank that is contacted may “make a market” on the option, meaning thatit provides both a bid (a price at which it is willing to buy an optioncontract) and an offer (a price at which it is willing to sell the sameoption contract) to the bank seeking the price on the option. The bankseeking the price may choose to buy, sell or do nothing. The benefit ofthe direct market is that a bank may contact many banks and deal witheach of them, thus transferring a lot of risk to a number of differentbanks. The disadvantage is that the bank will have to cross thebid/offer spread (the difference in price between the offer to sell andthe bid to buy the same option contract) and will therefore notnecessarily find the best price in the market.

In the broker market, the bank seeking a price on an option (referred toas the “Interest”) contacts a broker who in turn makes a market on theoption as a result of contacting many other banks. The particular optionthat the Interest bank wishes to deal is known as the specific-interest.The broker attempts to solicit a price on the specific-interest optionfrom banks called market makers. The broker then assembles the best bidand best offer from the prices obtained from the market makers, and thebroker provides this composite price to the Interest. At no stage untila deal is done will anyone except the broker know the identity of eitherthe market maker banks or the Interest. When the Interest sees theprice, it may buy or sell or do nothing, or, if it wishes, contribute abetter bid or offer to the composite price.

Once the Interest has seen the price and has responded in some way, thebroker may then show the price to other banks. These banks may in turnprovide better bids and offers inside the price until the bid and offermeet and a deal is made. At this point the broker will identify thecounterparties to each other, and, if they are willing to deal with eachother from a credit perspective, the remaining economic details of thedeal are agreed to and the deal is confirmed. The deal occursbilaterally between the two banks. The broker is not involved as aprincipal but acts as an arranger in return for a fee.

One disadvantage of the broker market is that the banks themselves mustundertake a final stage of credit checking after a bid and offer are metand after the identity of each party is revealed. The imperfect natureof the credit process can cause problems in a fast-moving market.

All derivatives reference the price of an underlying asset, and in thecase of currency options, this asset is foreign exchange spot rate. Adisadvantage of the broker market is that market makers are often heldto certain option prices when the spot rate of exchange for theunderlying currency changes dramatically. Typically, market markers donot like to be held to quoted prices as the spot rate of exchange movesrapidly. This is because the spot price may be “breaking out” of arange, in which case the market perceives options to be cheap and willtry to buy them on the market maker's offer, or because the price isdrifting back into an old range which can mean that the market islooking to sell. Brokers attempt to protect market makers by not quotingtheir prices if the spot rate moves dramatically, but this is done on anad-hoc basis.

Similarly, market makers wish to avoid having stale prices on themarket. Brokers try to avoid quoting stale prices, but what is meant by“stale” is generally not clearly defined, and the misunderstandings thatarise from this lack of clarity frequently result in prices beingwithdrawn from the market too soon or too late.

A form of trading that does not go through either the direct or brokermarkets is so-called “autodealing” or “volatility surface trading.” Theprices for puts and calls are often quoted in units of volatility,rather than in monetary terms. Volatility is a measure of the change invalue of an option contract which may be calculated if the spot rate,strike price, time to expiry and the foreign currency interest rate anddomestic currency interest rate are known. The relationship betweenthese parameters is expressed as the Black-Scholes equation, auniversally adopted methodology. After an option contract is bought orsold at a specified volatility, the volatility is converted into amonetary purchase price for the option contract using the Black-Scholesequation. A volatility surface is a three-variable relationship whereina volatility price can be calculated so long as a given time to expireand given strike price are provided.

Large banks typically provide prices on many option contracts each day,both to traditional clients and to smaller banks. To avoid overloadingusers with hundreds of pricing requests, many large banks haveinternally implemented volatility surface trading systems, which allowsmall trades to be priced automatically. The impetus behind the creationof these systems has been to reduce the manual workload for traders,whose time is quite valuable.

The volatility surface trading system must have or be able to calculatethe volatility of any option that is requested. The banks thereforeprovide a “surface” of volatility, defining the volatility, and thusprice, of any option that falls within the defined two-dimensional spaceof time-to-expiry and strike. This surface is updated throughout thetrading day. The normal implementation has been to provide the systemwith a series of volatilities (hence prices) for commonly traded strikesand tenors. The system can then interpolate according to certain rules a“surface” of volatilities for each desired strike and tenor.

A bank customer who requests an option contract at a particulartime-to-expiry and a particular strike price is given an automatic pricequote for the transaction in terms of volatility, which is convertibleinto a monetary price. The rules tend to vary from bank to bank but arebroadly similar in general terms. Once the “surface” has been created,it is a relatively simple matter to provide a volatility for any optionsimply by looking up the correct strike and tenor. Users of the systemhave the advantages of quick pricing of small specific interests.However, the interpolation of volatility surfaces tend to vary from bankto bank because each bank has a separate set of rules for adopting asurface.

Although banks' interpolation rules are broadly similar, they aredifferent enough to cause economically significant differences involatilities from different banks for a particular interpolated option.This can lead to arbitrage, wherein market participants take advantageof small price differences in equivalent option contracts, to thedetriment of the banks making the market.

Accordingly, an accessible electronic trading system that providescounterparties a means for assuring credit before a deal takes placewhile maintaining anonymity is desirable. Such a system would alsoprovide market makers with the means, for every price and every currencypair: to define the exact spot price that should result in either a bidor an offer becoming invalid, to automatically withdraw invalid prices,to define a time cut-off for each price, and to automatically withdrawprices at the defined time cut-off. It is also desirable to provide asystem that limits arbitrage on volatility surface trading.

The design and implementation of any automatic or computerized tradingsystem is difficult. Designing a system which accounts for thecreditworthiness of the buyer and seller users of the system andseparately maintains current prices for options is especially difficultsince there is a complex relationship between credit worthiness and theacceptable option contract price. Existing electronic or computerizedtrading systems which are not primarily designed for trading optionscontain inherent inefficiencies in either or both of these systemscomponents and in the time, cost, resources and price transparency.

U.S. Pat. No. 6,014,627 to Togher et al. describes a computerizedtrading system dealing with financial instruments such as foreigncurrency by selectively distributing anonymous price quotes inaccordance with pre-established credit limits. The system reviews creditinformation provided by counterparties using the system andautomatically determines whether a predetermined level of credit iscurrently available from a potential party to a transaction prior tosubmitting a price quotation to the other potential party based on theinformation provided. By prescreening bids and offers input by parties,each party is only provided with “dealable” prices from counterpartiesfor which credit compatibility exists. The system is directed to tradingforeign currency and not currency options and thus does not provide themore complex system requirements for trading option instruments.

U.S. Pat. No. 5,924,082 to Silverman et al. describes a negotiatedmatching system that uses a “matching computer” to identify a bid and anoffer from suitable counterparties based on transaction data and rankingdata supplied by each of the parties. Matched counterparties are thenprovided a communication link to further negotiate the terms of thetransactions.

U.S. Pat. No. 5,787,402 to Potter et al. describes a system for tradingcurrencies in which a user inputs the characteristics of the transactionit desires and the system automatically generates an offer in responseto the user's request. The user has a specified amount of time to acceptthe offer, after which the offer is updated.

U.S. Pat. No. 5,905,974 to Fraser et al. describes a system forautomated trading in which bids and offers are displayed on customers'terminal screens. A customer may hit a bid or lift an offer, whichinitiates transactions at a set price point. The system uses fivedifferent trading states in which customers with active bids or offersare given priority to make trades. The system is designed to rewardcurrent customers providing active bids and offers.

U.S. Pat. No. 5,832,462 to Midorikawa et al. describes an electronicdealing system that manages credit lines between customers and updatesthe credit lines as transactions occur between the customers. It alsodescribes grouping a set of customers into a home group for setting acommon credit line between the group and another customer.

The trading of options in financial instruments presents varying uniquecomplexities which have not been adequately addressed by the prior artsystems such as those discussed above. In addition, the advent of theInternet and related web-based and thin-client-based technologies nowprovides a platform for the development of a network-based currencyoption trading system and method, which the present invention addresses.

SUMMARY OF THE INVENTION

The invention provides an interactive electronic trading system foroptions in financial instruments which enables users to trade optionsunder controlled credit risk parameters and with mechanisms implementedwhich will maintain current pricing for option contract bids and offers.In one embodiment, the invention is directed to a system for dedicatednetwork-based and web-based interactive trading of currency options.Users of the system may provide volatility runs of currency options, maydeal on existing offers to sell or bids to buy, or may improve onexisting offers to sell or bids to buy. The system of the invention maybe set up so that trading is done in units of volatility for the optioncontract price, and after a transaction is completed, the systemconverts the volatility price into a monetary currency based contractprice. Users of the system of the invention may include, but are notlimited to, banks of all sizes and traders or dealers employed by banksor other financial institutions. Users of the system access the systemthrough a workstation. Workstations include desktop, laptop, notebookand handheld computers, web consoles, thin clients, mobile telephones,pagers, personal digital assistants and any other means that allow usersto enter or view displays of offer and bid information on optioncontracts. The system includes a system server, which may include one ormore computers for managing network resources, managing network trafficand operating protocol. The system includes one or more communicationlinks that receive and transmit communications between the users of thesystem and the system server, including communications to users that areparties to a completed currency option contract providing informationconcerning the completed contract. The communication between users andthe system server may occur through high bandwidth lines, such as ISDNlines, telephone lines, or wireless communications enabled by packetradio, spread spectrum, cellular technology, satellites and microwavetowers.

The invention is also directed to a system for automatic pricequotations for a requested option contract. The system includes userseach having an internal volatility surface, and a protocol for pollingthe internal volatility surfaces for prices on the requested optioncontract. The lowest price is provided to the user requesting the optioncontract.

The invention also provides a method for providing automatic pricequotations for a requested option contract. When a request for an optioncontract is received, the internal volatility surface of one or moreusers is polled to obtain prices for the requested option contract. Theprices obtained from the poll are compared, and the lowest price isprovided to the user requesting the option contract.

The inventive system for the automated trading of option contractsensures trades are completed between creditworthy customers bycategorizing the users into discrete tiers. For example, users who areassigned to a first tier can perform nearly all of the transactions orfunctions available on the system. First tier users can make volatilityruns, can improve offers to sell and bids to buy options or may deal onoffers to sell and bids to buy options. Users in the second tier whodeal in smaller volumes of option contracts than first tier users aremore restricted in their use of the system. For example, they may onlybe permitted to improve offers to sell or bids to buy options or to dealon offers to sell or bids to buy options. Alternatively, there can beadditional user tiers such as a third tier of users who are restrictedonly to dealing on offers to sell or bids to buy options.

The system of the invention may further include a system forautomatically withdrawing quotes for offers to sell or bids to buyoptions contracts after an expiration of a certain period of timedefined by the user providing the quotes. The withdrawal of quotes isbased on a protocol corresponding to a period of time defined by theuser offering the option contract. The system for automaticallywithdrawing quotes may also permit automatic withdrawal of quotes upon aprescribed movement in the market value of the financial instrumentunderlying the option contract. The system includes a target value forautomatic withdrawal of the financial instrument defined by the user anda protocol for comparing the defined value to the current market price.The system further includes a protocol for withdrawing the user's quotesif the user's defined value for the financial instrument equals thecurrent market price for the financial instrument.

Arbitrage avoidance is implemented by a method which includes the stepsof receiving a notification that a user's internal volatility surfacehas changed, polling the user's internal volatility surface for pricesof indicative option contracts having prices stored by the system,comparing the current prices stored by the system and providing anotification if the prices obtained from the internal volatility surfaceare arbitrageable against current prices stored by the system.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a main screen for dealing on-the-run options, such asAt-The-Money Straddle and Risk Reversal options for a given currencypair and provides prices for current live volatility runs.

FIG. 2 shows a screen that provides summary data for a particular optioncontract, including expiry date, delivery date, strike price and spotreference.

FIG. 3 shows a screen that provides detailed pricing and contractinformation for an option contract selected by the user. Details includeoption strategy, trade, spot, expiry and delivery dates, relevant dates,prices and the system-calculated “greek” values (gamma, vega, spot deltaand vanna) that apply to the contract.

FIG. 4 shows a screen that provides all of the prices in the market fora particular currency pair and tenor.

FIG. 5 shows a screen that displays all of the trades for a particularcurrency pair and tenor that occurred over the previous week.

FIG. 6 shows a screen used for entering, improving, or turning off bidsand offers on specific tenors of on-the-run option contracts.

FIG. 7 shows a screen that confirms certain bids or offers submitted bya user for particular option contracts have been turned off.

FIG. 8 shows a screen used to view and confirm new prices andcorresponding currency face amounts on option contracts submitted to thesystem.

FIG. 9 shows a Run Entry screen, which allows users to enter prices forevery standard tenor of an on-the-run option for a selected currencypair.

FIG. 10 shows a screen used to enter a time-out, lower spot-out, upperspot-out and default size applicable to validity of prices entered onthe Run Entry screen of FIG. 9.

FIG. 11 shows a screen for dealing (selling or buying) specific tenorsof on-the-run options at the bid or offer price.

FIG. 12 shows a screen that identifies the counterparty to a trade andallows either party to display pricing details and to agree to the dealor to discuss details of the deal with the counterparty prior toagreement.

FIG. 13 shows a screen used to communicate with a counterparty after arequest has been made to discuss the deal using an online “chat”facility.

FIG. 14 shows a trade blotter screen that displays information about allof the deals of a particular user.

FIG. 15 shows the screen of FIG. 14, displaying totals by counterparty.

FIG. 16 shows the main screen for submitting specific-interests to thesystem.

FIG. 17 shows a screen for entering details on a request for aspecific-interest option contract.

FIG. 18 shows a summary flow chart for trading specific-interests.

FIG. 19 shows a summary flow chart for trading 2-leg specific-interests.

FIG. 20 shows a version of the trade blotter screen available to userswho need to download details of confirmed trades.

FIG. 21 shows a trade ticker screen which displays every trade which hasbeen done in the system. As a trade is made, it is added to the top ofthis screen.

FIG. 22 shows a summary flow chart for the normal trade process (offercycle).

FIG. 23 shows a summary flow chart for the normal trade process(acceptance cycle).

FIG. 24 shows a summary flow chart for the trade confirmation process.

FIG. 25 shows a summary flow chart for the trade negotiation process.

FIG. 26 shows a summary flow chart for the void trade process.

DETAILED DESCRIPTION OF THE INVENTION Definitions

Call: A call is an option contract to purchase at a certain strike priceand tenor.

Currency option contract: A currency option contract grants the rightbut not the obligation to make a specified exchange of a pair of foreigncurrency, buying one of the pair and selling the other in specifiedamounts, at a specified exchange rate (the “strike rate”), which is therate at which the option contract is exercisable. A currency optioncontract has a certain period of time before expiration, implying acertain date and time of expiry by market convention; the time to expiryis called the “tenor.” As the exercise of the option necessarily entailsthe purchase of one currency and the simultaneous sale of the other, thecurrency being purchased by the option-holder is referred to as the“call” currency, the other is referred to as the “put” currency. Allcurrency options contracts specify the call and put currencies and theiramounts at their inception. Calls on the underlying currency pair'ssingle-unit currency are referred to simply as “call options” or“calls,” while options in which the put currency is the underlying'ssingle-unit currency are referred to as “put options” or “puts” forsimplicity.

Delta: Currency options are typically identified by and traded on thebasis of their delta rather than their strike price in monetary terms.Delta measures the sensitivity of an option's value to its underlyingcurrency-pair's market price movement. It is the ratio of the absolutechange in value of the option as a percentage of the change in marketvalue of the underlying cash rate. Deltas are expressed in percentagevalue from 0 to 100. Hence, an option whose value changes by half of themarket rate has a delta of 50. A call option gains value as theunderlying exchange rate appreciates and will lose value as itdepreciates. Thus, for a call, delta is near 100 when the marketexchange rate for the underlying call currency is well above theoption's strike rate (the option is “in-the-money”). Likewise, delta isnear zero when the market exchange rate for the call currency is wellbelow the strike rate (the option is “out-of-the-money”). Put optionsare the reverse. A put option is in-the-money when delta is near zeroand the market exchange rate for the put currency is well below theoption's strike rate, and a put option is out-of-the-money when delta isnear 100 and the market exchange rate for the put currency is well abovethe option's strike rate.

Delta neutral: Deals are often transacted on a “delta neutral” basis,meaning that the instantaneous spot risk to each bank (the economic riskthat derives from the movement in the spot rate, quantified by delta) ishedged by the bank also agreeing to exchange an amount of the underlyingcurrencies that offsets the option's sensitivity to the underlying'sspot rate. These “delta hedges” are usually exchanged for “spot” value(by convention usually two banking days after the transaction date), butare frequently exchanged for “forward” (future) value. This exchange ofdelta hedge is effected at the same underlying exchange rate (“spotrate”) upon which the option's value is determined, thus removing the“spot risk” from the options transaction.

Exercise: Some options are limited to exercise on a certain date whereasothers may be exercised at any time from inception until expiration.“European exercise” means that the option can only be exercised on thelast day of its life. “American exercise” means that the option can beexercised at any time prior to expiration.

On the-run option: An on-the-run option is a straddle (a simultaneouspurchase of a put option and a call option on the same currency pairwith the same tenor and strike rate), struck at-the-money-forward (ATMF,meaning that the exercise price is same as the current market price ofthe underlying transaction at the same maturity) for a standard tenor(for example, expiring in one month's time).

Put: A put is an option contract to sell at a certain strike price andtenor. Run: A dealer's set of prices to buy and sell the commonly tradedround-date tenors for on-the-run options in a particular currency pair.Options whose strike rates, tenors, or other features make them“off-the-run” are also traded, but less commonly.

Specific interest options: Specific interests are off-the-run optionsthat have one or more special features. By convention, specificinterests are posted into the dealing community on a request for quote(“RFQ”) basis by the interested party, at which point dealers will makeone- or two-way prices.

Spot rate: The spot rate is the current market rate of the underlyingtransaction to the option contract. The spot rate for currency optionsis the quotation for an exchange of currencies occurring typically twobank business days after the date of quotation. For a call, when thestrike price is below the spot rate of exchange, the option is said tobe “in the money.” Similarly, when the strike price is above the spotrate of exchange, the option is said to be “out of the money.” For aput, the reverse is true. When the strike price is below the spot rateof exchange, the option is “out of the money.” When the strike price isabove the spot rate, the put option is “in the money.”

Strike price: The strike price is the price at which the purchaser ofthe option contract can exercise the underlying transaction. In the caseof a currency option, the strike price is the exchange rate at which thepurchaser of the contract may exercise.

Tenor: An option's tenor is the amount of time until its expiry. In thecurrency options market there are standard tenors for the majority ofcontracts traded. These include expiry dates set in the future by oneweek, one month, two months, three months, six months, nine months andone year. Options with tenors other than these are traded, but they arenot considered “on-the-run.”

Volatility: The prices for currency options are often quoted in units ofvolatility, rather than in monetary terms. Volatility in this case is amarket determined rate upon which option value is determined. It is theannualized standard deviation for the underlying and bears a directrelationship to the option's value. This volatility figure, along withother contract specifics and market prices render option value (the“premium”) via the Black-Scholes options pricing equation, a universallyrecognized methodology. Because all other value inputs are determined(strike rate, tenor, call and put currencies), or determinable (the spotrate, forward rate, interest rates in each currency), volatility pricesfor options translate into cash prices that both buyer and seller of theoption nearly always agree on. Volatility is a key concept in optionstrading because it is typically used as a proxy for the premium price byall market participants. After an option contract is bought or sold at aspecified volatility, the volatility and agreed inputs ate convertedinto a monetary purchase price for the option contract using theBlack-Scholes equation.

Volatility run: A volatility run is a set of prices expressed in termsof volatility for every standard tenor for a particular currency pair ata particular strike price.

Volatility surface: An option's volatility input will depend on itsstrike rate and tenor. A volatility surface is a two-dimensionalrelationship plotted in 3 dimensions and defines a close estimate ofmarket volatility for an option on a currency pair, as specified bystrike and tenor. Options dealers often use internally-generatedvolatility surfaces to price specific interest options and to markoptions portfolios to market.

Underlying currency pair: Pairs of currencies trade for cash settlementamong professional dealers in the inter-bank market. Each currencypair's exchange rate is quoted in terms of the amount of one currencyrequired to purchase a single unit of the other. Which currency isassigned to be the single unit is determined by market convention.Currency options derive their value in part from the exchange rate levelat which the underlying currency pair is trading.

The invention addresses the specific problems inherent in designing anetwork-based trading system that facilitates the trading of optioncontracts. This invention provides an automated system capable ofhandling trades of options in financial instruments, such as currencyoptions, and their unique parameters and considerations. In oneembodiment, the invention addresses the trading of currency options byand between banks. Users of the system include, but are not limited to,banks of all sizes and traders or dealers employed by banks or otherfinancial institutions.

The system of the invention supports standard option products withtenors, for example, up to 1 year and can accommodate products withlonger tenors as well as non-standard options. The system of theinvention allows users to trade both on-the-run options andspecific-interests.

The system maintains a current database of volatility prices on optioncontracts and transmits them to all authorized system users. The systemof the invention may poll system users, or poll one or more volatilitysurfaces maintained by system users, to obtain a list of volatilityprices for a requested option contract. In either case, for each optioncontract, the system shows the best price available along with theamounts of currency for which the best bid or offer applies. It alsoshows the second-best bid and if desired other less preferential bidsand offers available if any. Typically, at no point prior to dealing arethe identities of the users disclosed to other users.

Users may obtain from the system a price on any specific-interest. Oncethe specific-interest is defined by the user, market maker users havethe opportunity to make a market on the option. The system may supporttrading in currency pairs including, but not limited to, the followingcurrencies: EUR (Euro), USD (United States dollar), JPY (Japanese yen),GBP (British pound), CHF (Swiss franc), AUD (Australian dollar), NZD(New Zealand dollar), CAD (Canadian dollar), SEK (Swedish krona), NOK(Norwegian krone) and GRD (Greek drachma).

The invention also provides a way for a user to identify thecounterparties with which it prefers to deal in terms of credit. Theuser of the system sees only the prices of counterparties with which theuser may deal in terms of credit. These “credit filters” promote systemefficiency by displaying only bids and offers on which the user maydeal. Using an online credit input screen, or an automatic file upload,each user defines the counterparties with which it can deal by providingfor each counterparty with which it will deal (1) the maximum tenor itcan deal to and (2) the maximum size (or maximum value at risk, “VaR”)of option it can deal for. The user may update these preferences as manytimes as it chooses. These preferences are stored in the system'scomputer database. The system operates a protocol whereby every time anew bid or offer is entered by a system user, the system consults thecurrent user preferences in the database to determine which user screensshould display the newly entered bid or offer.

The system of the invention can be managed so that it does not show to auser prices from a counterparty other than one with which the user candeal, nor will it show prices on an option that is of an inappropriatetenor or is too large. Each user sees only prices on which the userknows he can deal according to the data that the user has supplied tothe system. If two institutions meet on a price displayed by the system,the deal will be deemed to be binding. At that point, the user cannotturn down a counterparty on grounds of credit. Thus, the system of theinvention allows a great deal of flexibility to define credit filtersand to see prices that are tradable, but requires in return that userstake the burden of responsibility for credit decisions upon themselves.

Alternatively, the user may view the prices of all counterparties,regardless of whether the counterparties meet the user's creditrequirements. The system may also be configured so that a user may viewthe prices of all counterparties, but will be able to discern by anon-screen indicator the prices which meet the user's creditrequirements. An example of such an on-screen indicator is a specificcolor for prices that do not meet the user's credit requirements.

A user may also directly deal with other users. Users can specifyanother user or set of users to contact for prices on a one-to-onebasis. Users may choose a list of other users by name.

Users may also request prices from other users anonymously, based onhistorical price-making performance ranking. A user may request a priceon a given currency pair based on performance of a specified number oftop users, based on the users' liquidity performance per currency pairand per tenor over a specified time period. For instance, for USD/JPY,User A may request prices from three users who have provided the bestperformance for the three month tenor, over the last month. Or, a usermay request a price on a given currency pair based on performance of aspecified number of top users, based on the percentage of time for whichthe users have provided the best price, over a specified period time.

The system of the invention also provides a means for automaticwithdrawal of stale quotes. The system of the invention allows users todefine a time cut-off for each offer or bid (a “time-out”), after whichprices are automatically withdrawn. The system allows withdrawal ofprices if there is more than a prescribed movement in the value of theunderlying currency. The user may define a particular barrier spot rateprice for each currency pair called a “spot-out.” If the spot price of acurrency pair reaches the spot-out defined by the user, the user's bidsand offers for that currency pair are automatically withdrawn. These“time-out” and “spot-out” facilities allow market makers to be protectedfrom stale prices and large market moves. The availability of thesefeatures should result in greater willingness to make prices and thus,greater liquidity throughout the system.

The system also provides priority rules for bids and offers. The systemprioritizes bids and offers according to two criteria: first, by theprice level of the bid or offer; second (as to equal prices), by thetime the bid or offer was submitted. These rules create greatertransparency in the market than is currently available. The priority ofbids and offers by price is displayed on the screen in that only thebest current price, along with the second best price, is displayed for aparticular option contract. The priority among users at the same priceis not reflected on-screen except that when a user joins at a particularprice level the additional volume will appear on-screen as an increasein the volume. A single volume is displayed for each price whichrepresents the total of the individual volumes at that particular price.

New bids and offers are constantly being submitted, and as time passesand the spot market moves, bids and offers will time-out and spot-out.Accordingly, the price of each option changes continuously. Users seethese changes virtually instantaneously, further increasing transparencyin the market.

Transparency of the market is further increased by the system of theinvention with a screen that indicates the depth of the market, shown inFIG. 4. This screen gives the user the ability to view all pending bidsand offers for any given currency pair and tenor as well as the amountavailable to trade at each price. The depth of market stack may bedisplayed best to worst bid/offer, with the user's position, if any,appearing in the queue in a different color. Therefore, the depth ofmarket screen allows a user to view, for instance, how many banks arepotential dealers on a particular currency option, how much volume isavailable, and whether any bids or offers are out of line.

The system calculates the actual price from the volatility price of eachcontract in real-time and displays the actual price upon request. Thisfeature is an improvement over current practice where price fromvolatility is calculated after the deal is done, and can be disputed ifa user does not agree with the inputs that have been used for thecalculation. In the system, the spot rate, forward rate and interestrate information that are required for the calculation of price areprovided by live feeds from market standard information systems as wellas from the users' own internal feeds. Preferably, these feeds may onlybe amended by mutual consent.

The system may also include a means to resolve disputes betweencounterparties. The system provides the ability to download the detailsof a deal once it has been confirmed. At this point, a support person ofthe system can mediate a dispute between the counterparties. Since alldeal details are displayed to the user before it deals, such situationsshould rarely arise.

After all details of the deal are agreed upon, the deal is posted to thesystem database. Each user is able to see all the trades it has made andis given the opportunity to download the details locally. Thiselectronic download saves a great deal of manual booking and ticketwriting. The system also keeps a record of when users have made marketson specific-interests or have provided volatility runs, in order toassess to what extent these users fulfill any obligations they may haveas market makers.

As an adjunct to the broker functions that the system provides, thesystem may also allow users that are price-takers to deal automaticallyeither on volatility surfaces provided by users that are price-makers onthe system or on the prices provided by price-makers when the volatilitysurfaces maintained by these users are polled by the system.

Access and Security. Each client organization may have several log-insto the system. Most users will have their own log-ins and customizetheir screens to suit their particular roles. A separate log-in can beprovided to the credit department to allow users to upload the creditfile. Each access is password protected.

The heaviest users of the system can be provided with dedicated highbandwidth lines, such as ISDN lines, for direct access to the system,while lighter users may access the system through a standard Internetaccess or telephone line. The system may also be designed to run onnetworks other than the Internet, such as dedicated user networks.

The security of the system is assured by basing it on a secure serverwith a hot backup. For example, 128-bit RSA, public key-based encryptionsystem may be used for all transmissions.

Management Information. The system collects data on deals done andnumber of markets made. Collection of data on deals done allows reportsto be prepared to show each user what market share it has and providesthe input to the brokerage billing process. The system of the inventioncollects data on the number of markets that each user has made, and theproportion of time that volatility runs have been kept live in order toassess the user's performance relative to its market-making obligations.

Technical Overview. The system transmits prices to, and responses from,users via commercially available software packages. This messagingsoftware runs on its own dedicated server. Locally, information ishandled by an operating system such as JAVA® (available from SunMicrosystems) or Windows®-based graphical user interface (available fromMicrosoft). Contract details may be entered and options details arecalculated using a pricing screen, which calculates deal details ofcurrency options.

Tiers of Users. In order to promote liquidity and to cater to thediffering needs of different types and sizes of users, each user may beplaced or “tiered” in two or more tiers. Each tier has different accesscapabilities, trading capabilities and fees. In one embodiment of thesystem of the invention, the users are tiered in one of three tiers.

First Tier. In a currency option trading system, the users in the firsttier are the major currency option market makers. These users providevolatility runs and volatility surfaces, make markets onspecific-interests, ask for specific-interests, and are able to provideimprovements to existing prices. When trading through the system, firsttier users pay one rate of brokerage (lower than the current marketaverage) for regular deals. The first tier users pay another, even lowerrate, if they deal on an option where they previously have made a marketon the system. For example, if, a user made a market on the system inone month EUR/USD straddles as part of its volatility run for thatcurrency, and subsequently hit a bid that was put inside its price, theuser would pay the reduced level of brokerage. The pricing system isintended to encourage the provision of prices. If, on the other hand, afirst tier user does not fulfill its market making obligations, it facespenalties, such as increased brokerage rates or withdrawal of its marketmaking privileges. First tier users are required to provide volatilityruns to ensure adequate market coverage by the system. The provision ofvolatility surfaces, unlike the provision of volatility runs, isentirely voluntary.

Second Tier. The second tier comprises the bulk of the users classifiedaccording to credit rating. They can make volatility runs, improveexisting prices and ask for specific-interests, but they cannot makemarkets on specific-interests. They pay a flat rate of brokerage on alldeals. This rate may be significantly lower than current market pricesbut higher than that for first tier users. They are also permitted touse the autodealing function of the invention, as described above. Inaddition, they are able to use the autodealing function of the inventionfor deals under a certain threshold in terms of size in certain liquidcurrency pairs. For second and third tier users, the system provides anautodealing price on their specific-interest from the lowest bid andhighest offer that result from the system's poll of the volatilitysurfaces maintained by first tier users, or alternatively, from thevolatility surfaces created by the system from the volatility surfacesprovided by the first tier users.

Third Tier. Third tier users are typically small regional users dealingin small size option contracts. They do not make any markets or improveexisting prices. They are, however, able to ask for specific-interests.

An example of the tiering functions and capabilities of a currencytrading system is summarized in the following table:

TABLE I Provide Bids/Offers For Provide Autopricing Penalty ForVolatility Volatility Ask Make Improve Surface Price Brokerage NotMeeting Tier Surfaces? Runs? Specifics? Specifics? Prices? Takers RateObligations First Yes Yes Yes Yes Yes No Flat rate Increased brokeragerate; lose market making privileges Second No Yes Yes No Yes Yes Flatrate None Third No No Yes No No Yes Flat rate None

The Two Tier Configuration. The system can be configured to include twotiers of users: price-makers and price-takers. The first tier in the twotier configuration corresponds to the first tier of the three tierconfiguration, i.e., market makers who provide volatility runs andvolatility surfaces and who make specific interests. The second tier inthe two tier system is a hybrid of the second tier and the third tier inthe three tier system. The second tier user in the two tierconfiguration can be a price-maker on volatility runs, it can ask forspecific interests and be an autopricing surface price taker. The tieredfunctions and capabilities of a two tier currency trading system issummarized in Table II:

TABLE II Provide Bids/Offers For Provide Autopricing Penalty ForVolatility Volatility Ask Make Improve Surface Price Brokerage NotMeeting Tier Surfaces? Runs? Specifics? Specifics? Prices? Takers RateObligations First Yes Yes Yes Yes Yes No Flat rate Increased brokeragerate; lose market making privileges Second No Yes Yes No Yes Yes Flatrate None

Autodealing on Volatility Surfaces. The system of the invention alsoprovides a means for eliminating arbitrage, which occurs upon trading oninternal volatility surfaces, by providing computerized autodealing oncomposite prices derived from many different internal volatilitysurfaces.

Autodealing occurs by a poll of first tier users. For each autodealingprice needed, the system polls a computer of each first tier user, andeach first tier user's computer provides a price for the option sought.The price provided by each first tier user is based upon a price derivedinternally by the first tier user, presumably by interpolation of avolatility surface created by the first tier user according to theinterpolation rules of that user. The system of the invention providesthe best and second best prices to the user who requested the price.

Preferably, market-making users maintain a volatility surface that canbe used to specify the volatility used for options expiring on everybusiness day in the next year and for every delta from 5% to 95%. Eachmarket-making user has a volatility request mechanism on a web ornetwork server on the user's premises. The system of the invention hasan Application Program Interface (API) that resides on the user's web ornetwork server. The API defines the formats for requests from and pricesto the system of the invention. Prices may be generated dynamically toavoid holding the complete surface in memory.

Using the system, surface price takers can ask for an anonymous surfaceprice. Once a deal is executed in this method, it can still be declineddue to credit. To assure they won't be declined due to credit, surfaceprice takers can identify themselves when requesting a surface price.The system of the invention will display the best price given creditavailability. Once executed using this method, the deal cannot bedeclined on credit.

If there is an arbitrage between two prices returned by the first tierusers, the bid/offer spread cross, causing a large potential loss to themarket maker bank who has unknowingly crossed over the bid/offer spread.The system of the invention eliminates the arbitrage by allowing theuser to trade on only one side of the price.

The system of the invention also has a feature to avoid arbitrage withprices held by the system. Each time a first tier user changes itsinternal volatility surface, the first tier user informs the system ofthe invention of the change. The system then polls the first tier user'scomputer for prices of certain indicative options. The indicativeoptions may include, for example, 10% and 25% delta puts and calls andat-the-money forward straddles for all of the on-the-run tenors (1month, 2 months, etc.). The prices of the indicative options arecompared to the highest bid and lowest offer for each of the indicativeoptions currently held by the system. The first tier user that iscontributing the prices for the indicative options will be notified bythe system if the prices contributed are arbitrageable against thehighest bids and lowest offers stored by the system. With thisinformation, the first tier user may alter its volatility surface tocorrect for the arbitrage. If the arbitrage is not eliminated by thefirst tier user, the system will eliminate the arbitrage by onlyallowing users to trade on one side of the price.

Autodealing may also occur using a volatility surface created by thesystem of the invention. First tier users contribute data for avolatility surface for each currency pair that they have committed tomake markets for. The system of the invention accepts these surfaces ina pre-specified format from users and then uses these multiple surfacesto provide a composite price to give to a surface price taker. The“pre-specified format” will be a very fine grid of deltas and tenors,i.e., with a large number of data points (defined option volatilities)making up the surfaces. The reason for requesting a finely defined gridis to avoid the need to perform interpolations from a coarse grid in thesystem of the invention itself. Users' interpolation rules, thoughbroadly similar, vary sufficiently to cause economically significantdifferences in volatilities for interpolated options even where thedefined option volatilities are identical. The system of the inventiongreatly reduces the effect of varied interpolation rules because thefiner the grid, the smaller the differences are. These surfaces willspecify the volatility to be used for options expiring on every businessday in the next year and for every delta, in 5% increments, from 5% to95%. First tier banks also quote a bid/offer spread (in terms of basispoints) that the system uses to create two-way prices around thesemid-market volatility levels. These users provide the surfaces to thesystem of the invention in the form of an uploaded file.

The updating of information on users' volatility surfaces allows thesystem to keep the values consistent with the way currency options arecurrently trading. Updating occurs in two stages. First, the 50%-deltavolatilities on the surface are updated to be consistent with thecurrently tradable volatility run. Then, the off-the-run volatilitiesfor options whose deltas are not 50% are adjusted to maintain the samerelationship with the 50%-deltas as was specified in the originaluploaded surface. This updating feature provides an advantage overvolatility surface trading systems implemented individually by largeusers because in the system of the invention stale prices are not quotedfrom the volatility surfaces as the volatility market moves.

EXAMPLE 1

An example of on-the-run options traded according to the method of theinvention is as follows.

Input Screen. FIG. 1 is a screen for dealing on-the-run options. Thescreen provides the current live volatility runs for the GBP/USDcurrency pair. This screen could also be configured to show the currentlive volatility runs of more than one currency pair. Each user's deskmay customize which currency pair or pairs that appear on the screen.For each currency pair, prices are shown for all of the standard tenors(for at the money forward (ATMF) straddles) as well as for one month 25%delta strangles (a combination of a put and a call in the same currencypair expiring the same day, where the put and call have different strikeprices) and risk reversals (the simultaneous sale and purchase of both acall and a put with the same expiration month and with different strikeprices or with the same strike prices and different expiration months).

The screen of FIG. 1 shows the prices for GBP/USD contracts. The “spot”30 is located on the upper left hand corner and indicates the currentspot price for the currency pair from which all contract details will becalculated. The user can also see what cut-off convention (either the“New York Cut” with options expiring at 10 a.m. New York time, or the“Tokyo Cut” with options expiring at 3 p.m. Tokyo time) applies to eachbid or offer. The cut-off convention abbreviated “cut” 32 is located onthe upper right hand corner of the screen. The price of the one-week(indicated by 1 W on FIG. 1) contract is shown by the following data.The best bid 34 and the best offer 36 are shown in the center as 10.10and 11.00, respectively. The 10.10 offer 36 is shown in a particularcolor, for example red, because this offer has been placed by the userof the system. A user that has not placed this offer would see thisnumber in a different color, for example blue. The amount of currencythat the price is good for is shown by the smaller numbers 38 underneaththe bid and offer. In the one-week contract, the small number 20indicates that options on 20 million GBP are being bid and offered.(According to market convention, 20 million GBP in the context of anon-the-run ATMF straddle means 10 million GBP are call options and 10million GBP are put options.) The smaller numbers on left and the rightof the best bid and offer show the second best bid 40 and second bestoffer 42, if any, and the corresponding amount of currency that can betraded on them. In this embodiment, only those bids and offers providedby counterparties with which the user has specified that it can dealfrom a credit viewpoint are displayed.

From this screen (FIG. 1), a user can access additional usefulinformation. If the user clicks to the left of the contract price, onthe tenor period 44 (e.g., 1 M), a screen will appear that shows thecurrent details of the trade for that tenor. FIG. 2 shows an example ofthis screen for a 3 M EUR/USD contract. The screen of FIG. 2 providesinformation on expiry date, delivery date, strike price and spot price.When the user clicks on the “Pricer” button 46 of the screen of FIG. 2,additional information about the option contract, such as price inmonetary terms, spot to delta ratio, hedge, gamma vega, and vannaappears in an additional screen, shown in FIG. 3.

When the user clicks on a price in the middle columns of FIG. 1, ascreen that provides depth of market appears, shown in FIG. 4. Thisscreen shows all of the prices in the market for that tenor. The depthof market stack is displayed best to worst bid/offer, and the user'sposition, if any, is indicated by appearing in a different color.

The user may also view the transaction history of a particular tenorfrom the screen of FIG. 1. The user clicks on the “H” 48 located to theright of the prices for a particular tenor, and a transaction historyscreen for the tenor appears, as shown in FIG. 5. The transactionhistory screen shows the trades that have been done for that tenor overthe last week.

Improving or Joining Prices. The user can act on the price displayed onthe screen of FIG. 1 by double-clicking on the price itself, whichallows the user either to improve the price or to deal. If the userchooses to improve the price of, for example, the USD/JPY one-month, thescreen will appear as shown in FIG. 6. Versions of the screen of FIG. 6customized to specific options strategies, such as Straddles and RiskReversals and are also available in Deal mode (see FIG. 11). Thisembodiment includes entry/display fields for bid and ask price, faceamount, as well as upper, lower and time-out limits for the price.

The user can input its own bid or offer for a particular amount ofcurrency from the screen shown in FIG. 6. In this example, the user issubmitting a bid 102 of 10.00 on 30 million USD and an offer 104(denoted “Ask” in FIG. 6) of 11.00 on 30 million USD. From the screenshown in FIG. 6, the user may improve its own prices as well. Inaddition to specifying the level and the size of bids and offers, theuser may specify a time-out, e.g., how long the price is good for. Theuser specifies a time-out by entering the time in minutes that thesubmitted price is good for beneath “Timeout” 106 on the screen of FIG.6. The user may also specify a spot-out, the value of spot that is thetrigger for canceling the bid or offer. The user specifies an upper spot108 and a lower spot 110 on the screen of FIG. 6. If the spot pricemoves outside of or equal to these limits, the submitted price will betaken off.

If the user chooses the “Off” button 112, a previously submitted pricefor that tenor will be removed. When the Off button is selected, thescreen of FIG. 7 appears to confirm that a particular price is turnedoff.

If the user chooses “Submit” 114 on the screen of FIG. 6, the user mustconfirm its prices. When the user clicks on the “Submit” button of FIG.6, the screen of FIG. 8 will appear. The user selects “Confirm” 116 onthe screen of FIG. 8 to confirm its prices.

Once the user submits and confirms its bid and/or offer, the system ofthe invention transmits the new price to all users. If the user hasjoined the bid, i.e., has submitted a bid that is equal to the currentbest bid, the system of the invention transmits the same price as beforebut with an improved size on the bid. If the user has joined the bid andanother user trades at this bid, the user's bid will not be filled untilthe bids that were submitted before its bid are filled according topriority rules.

Users submit entire volatility runs to the system. The system provides aRun Entry Screen for inputting such volatility runs. A trader can enterindividual prices into the system for every contract in the run.Alternatively, by using the Run Entry Screen, the trader can defaultevery price to the current best price for that particular option in thesystem. By clicking on a particular entry, the trader can either jointhe market default price or change the price to a desired entry otherthan the default price. The Run Entry Screen also permits a trader toset a default size, a time-out, a lower spot limit and upper spot limitfor all entries in a run.

FIG. 9 shows an example of a Run Entry Screen for a US Dollar/CanadianDollar currency pair for at-the-money (ATM) straddles for each bid andoffer of a tenor, the screen displays a bid 120 on the left with acorresponding size 122 represented by the smaller number below the bid.Similarly, the number to the right is an offer 124 with a correspondingsize represented by the smaller number below the offer. To the right ofeach bid and offer is a button marked “C” 126 and a button marked “D”128. A trader who clicks on “C” 126 will clear the price and size forthat tenor. Clicking on “D” 128 puts the default size for the run. Atthe bottom of the Run Entry Screen, there are four larger buttonsentitled “Off Run” 130, “Reset” 132, “Submit” 134 and “Settings” 136.Selecting the “Off Run” 130 button removes all previously submittedprices for the currency pair. Selecting the “Reset” 132 button clearsall displayed prices and sizes in the dialog. Selecting the “Submit” 134button submits all displayed prices and makes the prices available andvisible to other users in the system.

By selecting “Settings” 136, the user accesses another display, anexample of which is shown as FIG. 10. In this display, a user can set atime-out 138, a lower spot limit 140 and an upper spot limit 142, aswell as a default size 144 for the run. After inputting these settings,the user can save the settings as applying to the volatility run byselecting “OK” 146.

To prevent arbitrage, if the user submits a run that includes a bid oran offer that crosses the bid-offer spread of any contract currently inthe system, the system notifies the user. The user is prompted by thesystem to confirm that it wishes to enter the bid or offer even thoughit crosses the spread.

If the user joins the bid/offer, (i.e. submits a bid/offer that is equalto a current bid/offer), the system will transmit the same price asbefore but with a combined, or “stacked,” size on the bid/offer. Forstacked prices, trades will be done on a first-in-first-out basis, i.e.the full amount of the first price at the level will be executed beforeany of the second or subsequent stacked prices are executed. Theseprices are displayed in an agreed color if the user is a part of thestacked price; otherwise they will appear in another agreed color.

A summary flowchart of the process for submitting a price to the systemis shown in FIG. 22.

Dealing On Prices. A user can deal on a price by double-clicking on thebid 34 or the offer 36 on the screen of FIG. 1, and choosing to “deal”148 rather than “improve” 150 on the screen of FIG. 6. When the userchooses to deal 148, the screen appears as shown in FIG. 11. This screenallows the user to sell at the quoted size and price or to buy at thequoted size and price. The system of the invention does not permit theuser to deal on prices the user itself submitted. (The user is notlikely to attempt to trade on these prices since they appear in adifferent color indicating to the user that it submitted the prices.)The user clicks on the “Sell” 152 button to accept the bid or on the“Buy” 154 button to accept the offer. Once the user clicks the Buy 154or Sell 152 button, the system shows the user the names of thecounterparty (or counterparties) with whom the user has dealt and thedetails of the trade, as shown in FIG. 12. The user can either “Agree”156 to the deal or “Chat” 160 about the terms of the deal by clicking onthe appropriate button in the bottom right hand corner of the screenshown in FIG. 12. Additionally, the user may click on the “Pricer” 162button in the bottom left hand corner of the screen of FIG. 12 to obtaina display of contract details. This display is shown in the screen ofFIG. 3. If no action is taken after 30 seconds, the deal isautomatically confirmed. The time remaining for taking action 164 isshown in the upper right hand corner of the screen of FIG. 12.

If the user agrees with the details (which are the same details shown tothe user before dealing) the user presses the “Agree” 156 button. Oncethe counterparty or counterparties have also agreed, the deal will beposted to the deal database. To prevent build-up of deal backlogs, thedeal is completed automatically three minutes after the user has pressedthe “Agree” 156 button with no response from the counterparty.

A summary flowchart of the process for dealing on a price is shown inFIG. 23.

If a counterparty disagrees with the deal details, the party can contacta member of the system's support team who will mediate between the twoparties to reach an agreement. This is achieved using the system'sonline chat facility, a one-to-one Internet communication channel, orthe phone. The online chat facility, which allows the user to hold anonline conversation with the relevant counterparty, appears as shown inFIG. 13. A summary flowchart of this mediation process is shown in FIG.24. A summary flowchart of the trade negotiation process is shown inFIG. 25.

Viewing Deals. Once deals are done, a user can see all of its deals inan on-line blotter, as shown in FIG. 14. The trade blotter screen ofFIG. 14 offers extensive filter capabilities, as well as the ability torecalculate, confirm and reject changes to trades. Another embodiment ofthis screen is available to users who need to download details ofconfirmed trades, shown in FIG. 20.

The trade blotter screen of FIG. 14 can be downloaded electronicallyinto the user's risk management system. A filter panel 166 is displayedon the right hand side of the screen. Information on the blotter may befiltered by the user so that the user may select to see totals of, forexample, currency pair, maturity, strategy, buy or sell, counterparty ortrader. FIG. 15 shows an example of the on-line blotter screen of FIG.14 with totals by counterparty shown. Additionally, the user can sortrecords on values shown in the columns “Currency Pair” 168, “Trade Date”170, “Strategy” 172, “Buy or Sell” 174, “Counterparty” and “Trader.” Theuser can sort columns by selecting the desired sort options on thefilter panel 166 of the screen of FIG. 14, or by clicking on the columnheader to sort by values in that column. Furthermore, the user canselectively filter records for one or more of the following categories:“Details unconfirmed,” “Not Downloaded” or “All for the user's banks” byselecting these categories on the filter panel 166. The deal details maybe downloaded to the user's own computer either manually by the user orautomatically, with the user's computer polling the system of theinvention to identify and download all new deals, with user-chosenfrequency, or automatically with the system of the invention alertingthe user's web or network server that deals are waiting. The user's webor network server can then request download of any deals. This blotterfacility represents a substantial time and effort saving compared to themanual transfer of deal information that is currently in use byvoice-brokers.

A trade ticker screen, shown in FIG. 21, is also available. This screendisplays every trade that has been made on the system. As a trade ismade, it is added to the top of this screen.

EXAMPLE 2

Most of the mechanics of dealing specific interests are very similar tothose of dealing on-the-run options. However, some aspects of dealingare particular to specific-interests.

Requesting a Specific-Interest. FIG. 16 shows the second of the two mainscreens of the system of the invention. FIG. 16 is the main displayscreen for dealing specific-interest options. From this screen the usercan enter an interest, which may be a standard strategy or a two-legcombination of strategies. There is no restriction on currency pairs foreither strikes or delta trades. Thus, a currency spread, for example,would be specified as a straddle in one currency pair and a spread witha straddle in another currency pair.

The screen of FIG. 16 can be filtered to show options in one particularcurrency pair, options to which a user has contributed a price, orspecific-interest options sought by the user. Each option has a seriesof fields that describe it and series of fields that show the price. Thepricing fields have the same convention as the on-the-run optionspreviously described in Example 1. A particular background color, forexample yellow, on the pricing fields indicates that the specificinterest shown was requested by the user.

A user requests a specific interest by clicking on the icon 180 on thespecific interest screen. This displays the Post Specific-InterestScreen, shown in FIG. 17. The user inputs its request for aspecific-interest on this screen. A specific-interest may be anystandard strategy or a spread between two standard strategies. Astandard strategy is one of the following: puts; calls; straddles;strangles (a combination of a put and a call in the same currency pairexpiring on the same day, where the put and call have different strikeprices); and risk reversals (a simultaneous sale and purchase of both acall and a put with the same expiration month and with different strikeprices or with different expiration months and the same strike price).Thus, a currency spread, for example, could be specified as a straddlein one currency pair spread with a straddle in another currency pair.The screen of FIG. 17 also allows the user to input up to a two-legcombination interest.

The details of the specific-interest to be entered by the user includethe currency pair 182, strategy 184 (put or call), strike 186, maturity188, delivery date 190, amount 192 and cut-off convention 194. In thecase of spreads, the user may specify an amount on one strategy and avega-neutral amount on the other. Vega is a measure of the degree towhich an option is sensitive to movements in the market level ofvolatility. When dealing on an option spread where one option is boughtand one option is sold, then it is possible by defining a differentamount of currency for the two options to avoid vega exposure to thespread taken as a whole. The vega from one option offsets the vega fromthe other. The system calculates the correct size for the secondstrategy to achieve vega-neutrality.

The screen of FIG. 17 displays several buttons at the bottom of thescreen, including Post 196, Pricer 198 and Calc 200. The Pricer 198button displays a screen providing details regarding the option contract(shown in FIG. 3) when selected. The Calc 200 button calculates thedelta if a strike is entered and the strike if a delta is entered. ThePost 196 button submits the specific-interest.

Market-Making Specific-Interests. Once the request for aspecific-interest is submitted, the system provides the request to allfirst tier users. First tier users choose whether or not to make amarket; however, a failure to do so would mean that the deal would notcount towards the fulfillment of the user's market making obligations,if any.

The screen shown in FIG. 16 is used by the market makers to deal onspecific-interests. If a market maker has supplied a volatility surfacefor the currency pair, the system suggests a rate based on that surface.In another embodiment, the system suggests a price based on a poll offirst tier users. The system will show a price input screen (FIG. 6, thesame input screen shown in the description of on-the-run options). Anyprice that is made for specific-interests may have spot-out and time-outlimits applied in the same way as for on-the-run options.

Dealing on Specific-Interests. Once the first price is made, theInterest and the first tier market makers can see the price. At thispoint the Interest may choose to buy or sell or to improve one side ofthe price. The first tier market makers who did not provide the pricemay improve the price but cannot yet deal on it. Once the Interest hasacted in any way (or once sufficient time passes if the Interest doesnothing) the option is “cleared” and released to every user of thesystem to improve, or deal on, the price.

Improving and dealing on-the price of specific-interests is handled inexactly the same way as for on-the-run options.

FIG. 18 shows a summary flow chart for trading specific interests. Bank1 submits a specific-interest at step 50. Market-making banks see thespecific-interest and enter prices at step 52. All banks see the pricesentered. Bank 2 decides to either trade or improve on the price at step54.

If Bank 2 decides to improve on the price, Bank 2 enters an improved bidand/or offer at step 56. All banks see the improved price step 58, andcan choose to either trade or improve the price.

If Bank 2 decides to trade, all banks will see any remainder of priceand amount that Bank 2 did not choose to trade at step 60. When Bank 2selects trade, it may view details of the deal on the Unconfirmed TradeScreen at step 62. Upon viewing the Unconfirmed Trade Screen (shown inFIG. 12), Bank 2 may choose to Agree, Reject or Dispute the deal.

If Bank 2 selects Agree, the system of the invention generates a tradeon the trade table at step 66. If the counterparties agree to deal withone another at step 70, the deal is confirmed and appears on theirrespective deal blotters at step 74. If the counterparties do not agreeto the trade, the system of the invention replaces or removes the priceat step 78.

If Bank 2 selects Reject on the Unconfirmed Trade Screen, the system ofthe invention removes or replaces the price at step 78.

If Bank 2 selects Dispute on the Unconfirmed Trades Screen, thecounterparties communicate directly with one another at step 84. If thecounterparties agree to deal with one another, the deal is confirmed andposted to their respective deal blotters at step 84. If thecounterparties choose not to deal with one another, the system of theinvention replaces or removes the price at step 78. The void tradeprocess is shown in the summary flowchart of FIG. 26.

FIG. 19 shows a summary flow chart for trading 2-leg specific-interests.

1-56. (canceled)
 57. A financial instrument option contract tradingsystem, comprising: a computer network comprising a plurality ofterminals each disposed in communication with an at least one computingunit, the at least one computing unit comprising a volatility requestmechanism which defines formats for requests and prices; a volatilitydata storage unit storing at least one set of volatility data associatedwith the option contract and respectively obtained from at least one ofthe plurality of terminals; a calculation unit supported by at least onecomputing unit and implementing a protocol for identifying from the atleast one set of volatility data a best price, the at least one set ofvolatility data obtained from at least one volatility surface, the atleast one volatility surface accessible by at least one associatedterminal of the plurality of terminals; and a communications unitsupported by at least one computing unit and communicating with a firstof the plurality of terminals the best price in response to a requestfor a quote from the first of the plurality of terminals for the optionscontract.
 58. The system of claim 57, wherein the best price is ahighest bid to buy the option contract and a lowest bid to sell theoption contract, the highest bid to buy the option contract and thelowest bid to sell the option contract defining a first range.
 59. Thesystem of claim 57, wherein the at least one computing unit is on auser's premises.
 60. The system of claim 57, wherein the at least onecomputing unit is a web server.
 61. The system of claim 57, wherein theat least one computing unit is a network server.
 62. The system of claim57, wherein prices are generated dynamically by the at least onecomputing unit to avoid holding the complete surface in the storageunit.
 63. The system of claim 57, wherein, on use, surface price takerscan ask for an anonymous surface price.
 64. The system of claim 57,wherein the plurality of terminals provide contributions to thevolatility surface, wherein a contribution comprises: a volatility pricecorresponding to an option contact for each of a series of deltas andexpiring every business day in the year following the date of thecontribution; and a bid/offer spread.
 65. The system of claim 64,wherein the series of deltas are from 5% to 95%
 66. The system of claim64, wherein the bid/offer spread is provided in terms of units ofvolatility.
 67. The system of claim 65, wherein the at least onecomputing unit specifies the volatility used for options expiring onevery business day in the next year and for every delta from 5% to 95%.68. The system of claim 58, wherein the plurality of terminals furthercomprises: a second terminal communicating an associated set ofvolatility data to the at least one computing unit, the associated setof volatility data comprising an associated bid to buy and an associatedoffer to sell defining a second range;
 69. The system of claim 68,further comprising: an arbitrage identification unit accessing thehighest bid to buy the option contract and the lowest bid to sell theoption contract identified by the calculation unit and, in response tothe communication of the associated set of volatility data, determiningif the second range does not mathematically overlap the first range. 70.The system of claim 69, further comprising the at least one computingunit identifying the existence of arbitrage to the second terminal inresponse to the second range not mathematically overlapping the firstrange.
 71. The system of claim 69, wherein the first terminal furthercomprises a user interface unit communicating the best price to a userof the first terminal.
 72. The system of claim 57, further comprisingthe at least one computing unit receiving an indication that at leastone of the at least one set of volatility data associated with theoption contract has changed.
 73. The system of claim 72, furthercomprising the volatility data storage unit receiving an updated set ofvolatility data corresponding to the at least one of the at least oneset of volatility data that has changed.
 74. The system of claim 69,wherein the first terminal is prevented from executing a purchase of theoption contract when the first range does not mathematically overlap thesecond range.
 75. The system of claim 69, wherein the at least onecomputing unit permits the second terminal to trade the option contractwith a terminal associated with the lowest bid to sell in response tothe first range not mathematically overlapping the second range.
 76. Thesystem of claim 69, wherein the at least one computing unit permits thesecond terminal to trade the option contract with a terminal associatedwith the highest offer to buy in response to the first range notmathematically overlapping the second range.
 77. The system of claim 69,wherein the at least one set of volatility data comprises a time-limitedset of volatility data having a predetermined period of time associatedtherewith, the at least one computing unit being arranged to withdrawthe time-limited set of volatility data in response to the predeterminedperiod of time expiring.
 78. The system of claim 69, wherein the atleast one set of volatility data comprises a value-limited set ofvolatility data having a predetermined threshold value associatedtherewith, the at least one computing unit withdrawing the value-limitedset of volatility data in response to a current market price for theoption contract being equal to or crossing the threshold value.